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(54) Bridge providing communication betvi/een different impiementations of object request 
brokers 



(57) Systems and methods for providing communi- 
cation between different implementations of object re- 
quest brokers are provided. A bridge including a proxy 
object allows communication between the object re- 
quest brokers. The proxy object within the bridge stores 



the server object reference in its reference data. The 
proxy object translates messages (e.g., requests and 
responses/exceptions) to the transfer protocol of the 
server object and redirects these messages according 
to the server object reference stored in the proxy ob- 
ject's reference data. 
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Description 

The present invention relates to object-oriented 
computer systems. In particular, the present invention 
is concerned with a bridge allowing communication be- 
tween different implementations of object request bro- 
kers. 

As individual computer systems increasingly be- 
come more powerful and complex, the integration of 
these heterogeneous computer systems becomes a 
very desirable yet difficult task. Users' expectations for 
interoperability have increased dramatically due to the 
availability of highly interoperable platforms such as 
UNIX, Microsoft Windows and Apple Macintosh. Unfor- 
tunately, vendor-specific solutions for integrating heter- 
ogeneous computer systems have generally been un- 
satisfactory. This is especially true because vendor-spe- 
cific solutions require upgrades to take into account new 
product releases. 

The Object Management Group (OMG) has prom- 
ulgated standards for nonvendor-speclfic solutions for 
heterogeneous systems integration. At the heart of 
OMG's standard is the Common Object Request Broker 
Architecture (CORBA). CORBA Is a distributed environ- 
ment defined using object-oriented concepts to hide all 
differences between programming languages, operat- 
ing systems, hardware platforms, and object location. 
This interoperability is achieved through well-defined in- 
terface specifications at the application level. 

Well-defined protocols exist for allowing systems to 
communicate by agreeing to certain standards that will 
be used. The Open Systems Interconnection (OSl) sev- 
en layer model is possibly the most widespread of these 
protocols. The lowest layer, the Physical layer, de- 
scribes how the physical network is accessed. The Data 
Link layer provides reliable transmission across a phys- 
ical link. The Network layer deals with connection es- 
tablishment and routing. The Transport layer provides 
reliable end-to-end transmission. The Session layer is 
concerned with connection control. The Presentation 
layer deals with data syntax and transparency to the ap- 
plications. Lastly, the upper layer, the Application layer, 
describes end-user functionality. Conceptually, CORBA 
resides in the Application layer. 

A central component of CORBA is the Object Re- 
quest Broker (ORB) which is the infrastructure for pro- 
viding transparent distributed communication across 
heterogeneous systems. The CORBA specification de- 
scribes all the standard interfaces for ORBs. The Basic 
Object Adapter (BOA) is an initial set of ORB interfaces 
for object implementations. 

CORBA is a peer-to-peer distributed computer fa- 
cility where all applications are objects. Objects can al- 
ternate between being a client and a server, where a 
client object is defined as being the originator of an ob- 
ject invocation and a server object Is defined as being 
the recipient of an object invocation. Server objects are 
also referred to as object implementations. Typically, ob- 



jects play both roles at one time or another. 

CORBA provides two mechanisms with or through 
which applications may communicate: static interfaces 
and dynamic interfaces. In static interfaces, the param- 

5 eters are defined at compile-time whereas in dynamic 
interfaces, the parameters are defined at run-time. 

Static interfaces include a stub and a skeleton. The 
client object links to the stub so that from the client's 
perspective, the stub acts like a local function call. 

10 Transparently, the stub provides an interface to the ORB 
that encodes and decodes the specified operation's pa- 
rameters into communication formats suitable for trans- 
mission. The skeleton is the corresponding server-side 
implementation of the interface. When the sender object 

IS completes processing of the request, the skeleton and 
stub return the results to the client, along with any ex- 
ceptions that are generated by either the server or the 
ORB. 

Dynamic interfaces are an alternative to compiled 

20 static interfaces. Dynamic interfaces include a Dynamic 
Invocation Interface (DM) and a Dynamic Skeleton Inter- 
face (DSI). The Dll is a generic facility for invoking any 
operation with a run-time-defined parameter list. A run- 
time interface description of the operation signature 

25 specifying the parameter list is retrieved during run-time. 
Thus, a request can be constructed to previously un- 
known operation or object type. The DSI is the corre- 
sponding server-side implementation of the interface. 
Use of the dynamic interface instead of the static inter- 

30 face is transparent to object implementation. 

Current CORBA ORB products support software in- 
tegration across multiple platforms. ORB implementa- 
tions may be generic across multiple platforms or plat- 
form-specific. Platform-specific ORB implementations 

35 offer many advantages including more efficient imple- 
mentation resulting from closer ties to the operation sys- 
tem. As an example, Sun Microsystems' NEO provides 
shared services extensions to the Solaris operating sys- 
tem. NEO supports standards such as OMG's CORBA 

40 specifications. 

Although platform-specific implementations of 
CORBA offermany advantages, there is a need for more 
efficient systems and methods for providing communi- 
cation between different implementations of ORBs. 

45 Embodiments of the present invention provide in- 
novative systems and methods for providing communi- 
cation between different implementations of object re- 
quest brokers. A bridge including a proxy object allows 
communication between the object request brokers. 

50 The proxy object within the bridge stores the server ob- 
ject reference in its reference data. The proxy object 
translates messages (e.g., requests and responses/ex- 
ceptions) to thetransfer protocol of the server object and 
redirects these messages according to the server object 

55 reference stored in the proxy object's reference data. 
Thus, an efficient mechanism for providing communica- 
tion between different implementations of object request 
brokers is achieved. 
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In one embcxJinnent, the present invention provides 
a method of providing comnnunication between a first 
object request broker utilizing a first transport protocol 
and a second object request broker utilizing a second 
transport protocol, comprising the steps of: storing with- 
in the reference data o1 a proxy object a reference to a 
server object; the proxy object receiving a request in the 
first transport protocol from a client object on the first 
object request broker; the proxy object translating the 
request to the second transport protocol; and the proxy 
object sending the translated request to the server ob- 
ject specified by the stored reference. 

In another embodiment, the present invention pro- 
vides a system for providing communication between 
different implementations of object request brokers, 
comprising: a first object request broker utilizing a first 
transport protocol; a client object on the first object re- 
quest broker; a second object request broker utilizing a 
second transport protocol, the first and second transport 
protocols being different; a server object on the second 
object request broker; and a proxy object that translates 
a request in the first transport protocol from the client 
object to the second transport protocol and sends the 
translated request to The sen/er object specified by a ref- 
erence to the server object stored in the reference data 
of the proxy object. 

The invention is described further hereinafter, by 
way of example only, with reference to the accompany- 
ing drawings, in which:- 

Fig. 1 illustrates an example of a computer system 
used to execute the software of an embodiment of 
the present invention; 

Fig. 2 shows a system block diagram of a typical 
computer system used to execute the software of 
an embodiment of the present invention; 
Fig. 3 is a block diagram of the interfaces between 
CORBA objects; 

Fig. 4 is a block diagram of a NEO bridge connect- 
ing to two different implementations of ORBs; 
Fig. 5 shows that the bridges of embodiments of the 
present invention provide bidirectional communica- 
tion between ORBs; 

Fig. 6 shows the high level architecture of a bridge; 
Fig. 7 shows components inside an embodiment of 
the bridge; 

Fig. 8 A shows a block diagram of a NEO client ob- 
ject invoking a server object on another ORB; 
Fig. 8B is a high level flowchart of a process of a 
NEO client invoking a server on another ORB; 
Fig. 9A shows a block diagram of a client object on 
another ORB invoking a server object on a NEO 
ORB; and 

Fig. 9B is a high level flowchart of a process of a 
client on another ORB invoking a server on a NEO 
ORB. 

In the description that follows, embodiments of the 



present invention will be described in reference to NEO 
ORBs on a Sun workstation running under the Solaris 
operating system. The present invention, however, is 
not limited to any particular ORB implementation, com- 
5 puter architecture or operating system. Additionally, the 
following describes communication between two ORBs, 
but communication among multiple ORBs may be ac- 
complished by an extension of the principles described 
herein. Therefore, the description the embodiments that 

10 follow is for purposes of illustration and not limitation. 

Fig. 1 illustrates an example of a computer system 
used to execute the software of an embodiment of the 
present invention. Fig. 1 shows a computer system 1 
which includes a monitor 3, screen 5, cabinet 7, key- 

is board 9, and mouse 1 1 . Mouse 1 1 may have one or more 
buttons such as mouse buttons 1 3. Cabinet 7 houses a 
CD-ROM drive 15, a system memory and a hard drive 
(see Fig. 2) which may be utilized to store and retrieve 
software programs incorporating code that implements 

20 the present invention, data for use with the present in- 
ventiori, and the like. Although a CD-ROM 17 is shown 
as an exemplary computer readable storage medium, 
other computer readable storage media including floppy 
disks, tape, flash memory, system memory, and hard 

25 drives may be utilized. Cabinet 7 also houses familiar 
computer components (not shown) such as a central 
processor, system memory, hard disk, and the like. 

Fig. 2 shows a system block diagram of computer 
system 1 used to execute the software of an embodi- 

30 ment of the present invention. As in Fig. 1, computer 
system 1 includes monitor 3 and keyboard 9. Computer 
system 1 further includes subsystems such as a central 
processor 102, system memory 104, I/O controller 106, 
display adapter 108, removable disk 11 2 (e.g., CD-ROM 

35 drive), fixed disk 116 (e.g., hard drive), network interface 
118, and speaker 120. Other computer systems suitable 
for use with the present invention may include additional 
or fewer subsystems. For example, another computer 
system could include more than one processor 102 (i. 

40 e., a multi-processor system) or a cache memory. 

Arrows such as 122 represent the system bus ar- 
chitecture of computer system 1 . However, these arrows 
are illustrative of any interconnection scheme serving to 
link the subsystems. For example, a local bus could be 
utilized to connect the central processor to the system 
memory and display adapter. Computer system 1 
shown in Fig. 2 is but an example of a computer system 
suitable for use with the present Invention. Other con- 
figurations of subsystems suitable for use with the 

so present invention will be readily apparent to one of or- 
dinary skill in the art. 

Fig. 3 is a block diagram of the static and dynamic 
interfaces between objects in CORBA. A client object 
202 makes requests to an object implementation 204 

55 (also called a "server object" as it services client re- 
quests). The terms client and server are relative tenms. 
A client may be a client with respect to a specific request 
and a server with respect to another request. Conse- 
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quently, these labels will vary according to the circum- 
stances. 

A client may also make a request utilizing a dynamic 
interface by calling a Dll 214. The Dll provides an inter- 
face to ORB core 208 that encodes and decodes the 
specified operation's parameters into communication 
formats suitable for transmission over the transfer me- 
dium. The Dll is dynamic because the parameter list is 
defined at run-time. 

After a request is encoded and transmitted over the 
transfer medium, the request Is decoded and passed to 
object adapter 210. If the specified object implementa- 
tion utilizes a dynamic interface, skeleton 212 (DSl in 
this case) provides a callback to a function implemen- 
tation for the request. The client and sen/er object may 
also interact directly with the ORB core through an ORB 
interface 216. 

It should be noted that the format of the request is 
the same over the transfer medium regardless of wheth- 
er a static or dynamic interface is utilized. In a preferred 
embodiment, the client and server objects utilize a dy- 
namic interface. 

A general protocol for communicating between 
ORBs is the Internet Interoperability Protocol (MOP). 11- 
OP is based on Transmission Control Protocol/Internet 
Protocol (TCP/IP) which is the protocol of the Internet. 
Additionally, MOP is specifically directed toORB-to-ORB 
interoperability In the description that follows. ORBs will 
be described as utilizing HOP to communicate. Howev- 
er, the use of this protocol is for illustrative purposes and 
other protocols may be utilized with the present inven- 
tion. 

Fig. 4 Is a block diagram of a NIEO bridge connect- 
ing two different implementations of ORBs. By different 
implementations (or types) of ORBs, it is meant that the 
ORBs utilize different transport protocols. A NEO ORB 
302 includes a bridge 304 which provides communica- 
tion with different implementations of ORBs. 

An ORB 306 utilizes HOP as its transport protocol 
which is a different transport protocol utilized by NEO 
ORBs, which utilize Distributed Object Management Fa- 
cility (DOMF). Bridge 304 allows NEO ORB 302 to com- 
municate with ORB 306 utilizing MOP. Although the 
bridge is shown in the NEO ORB, the bridge may alter- 
natively be in ORB 306. In either case, the bridge pro- 
vides bidirectional communication between the different 
implementations of ORBs, 

Also in Fig. 4, an ORB 308 includes a bridge 310. 
ORB 308 uses a transport protocol other than MOP. In 
this instance, bridges 304 and 310 provide communica- 
tion between ORBs 302 and 308 utilizing an intermedi- 
ate transport protocol of MOP. Thus, two bridges provide 
full interoperability between NEO ORB 302 and ORB 
308. 

Fig. 5 shows that the bridges of embodiments of the 
present invention provide bidirectional communication 
between different implementations of ORBs. In order to 
achieve full interoperability, a bridge should allow both 



a client object on a NEO ORB to invoke a server object 
on another ORB and a client object on another ORB to 
invoke a sen/er object on the NEO ORB. Typically, the 
bridge is hosted atop some ORB (e.g., the NEO ORB). 

5 As shown, a client 352 on a NEO ORB 354 may 

request to invoke a server 355 on an ORB 356. The cli- 
ent makes a request through the NEO ORB to a bridge 
357 which resides on the NEO ORB. The bridge is an 
application on the ORB that includes a proxy object 358. 

10 By proxy object, it is meant an object that translates and 
redirects requests to a server object. Thus, the proxy 
object translates the request and sends the request to 
server 355. The sender sends a response (or exception) 
back to the proxy object which translates the response 

IS before sending the response to the client through the 
NEO ORB. 

Client 352 utilizes a local object reference for the 
proxy object because the client and proxy are on the 
same ORB. However, the server is on a different ORB 
20 so the proxy object utilizes a nonlocal or foreign object 
reference forthe server. In order to more efficiently proc- 
ess the translation of the local object reference of the 
proxy to the nonlocal object reference of the server, the 
proxy object stores within its reference data the nonlocal 

25 object reference of the server. 

The reference data is a storage space within many 
objects. For example, in Basic Object Adapter (BOA) 
objects, the reference data space is 1K bytes. Thus, the 
nonlocal (or local as discussed in the following para- 

30 graphs) object reference for the server may be stored 
in the reference data of the proxy object. In a preferred 
embodiment, the object references for the server are 
stored as strings. 

Additionally, a nonlocal client object may request to 

35 invoke a local server object. As shown in Fig. 5, a client 
360 in ORB 356 may request to invoke a server 362 on 
NEO ORB 354. The client makes a request to a proxy 
object 364 in the bridge. The proxy object translates the 
request before it is sent to the server through the NEO 

40 ORB. The server sends a response (or exception) back 
through the NEO ORB to the proxy object. The proxy 
object translates the response and sends it to the client 
through the ORB on which it resides. The proxy object 
stores the local object reference of the server in the ref- 

45 erence data of the proxy object. 

Fig. 6 shows the high level architecture of a bridge. 
In a preferred embodiment, the bridge receives requests 
from two interfaces: DOMF and HOP. Communication 
between the bridge and NEO objects utUizes the DOMF 

so transfer protocol (e.g., including Dll and DSl). Commu- 
nication between the bridge and an object on other im- 
plementations of ORBs utilizes the HOP transfer proto- 
col. For example, a request from a client on a NEO ORB 
402 to a server on another ORB 404 is sent to a bridge 

ss 406 via DSl DOMF The bridge translates the DSl re- 
quest to an Dll HOP request. The response/exception is 
then received by the bridge via Dll and the bridge trans- 
lates it back to a DSl DOMF response/exception. 
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Also, a request from a client on ORB 404 to a server 
on NEO ORB 402 is sent to the bridge via DSI I lOR The 
bridge translates the DSI request to a DII DOMF re- 
quest. The response/exception is then received by the 
bridge via DII and the bridge translates it back to a DSI 
MOP response/exception. 

The HOP transfer protocol nnay be implemented in 
the bridge in numerous ways including embedding HOP 
in the bridge itself (thus, the NEO ORB core does not 
need to change) or modifying the host ORB to provide 
dual transport stacks of the DOMF and HOP transfer 
protocols. The first approach may be preferable as it is 
believed to be more efficient and portable. 

Fig. 7 shows components inside an embodiment of 
the NEO ORB bridge. In a preferred embodiment, the 
bridge includes two main parts: 1) the HOP implemen- 
tation that contains the I lOP transfer protocol (with part 
of the ORB interface) and 2) the bridge core that con- 
tains the code fortranslating DOMF requests/responses 
to HOP requests/responses (and vice versa). The first 
part is portable across several UNIX platforms. The sec- 
ond part is not necessarily portable since it interfaces 
with DOMF which may not be available in every ORB 
implementation. 

The bridge serves as the connecting entity between 
two ORBs, therefore a bridge is preferably automatically 
started after a machine is rebooted. A bridge may be 
implemented as a DOMF self-starting (persistent) serv- 
er. 

Fig. 8A shows a block diagram of a NEO client in- 
voking an object on another ORB. A NEO ORB 502 in- 
cludes a client 504 and a bridge 506. The bridge in- 
cludes a proxy object 508 which has a storage space of 
reference data 5 10. Another ORB 512 includes a server 
51 4. ORB 51 4 is a different implementation of NEO ORB 
502 as it does not utilize the same transfer protocol. 

If the client desires to invoke the sen/er, the client 
sends a request to the local proxy object. The proxy ob- 
ject translates the request into the transfer protocol of 
ORB 512 (e.g., HOP) and retrieves the nonlocal object 
reference of the server from reference data 510. The 
proxy object then sends the translated request to the 
server specified by the retrieved object reference. 

Proxy object 508 will receive the response (or ex- 
ception) from the server and translates the response to 
the transfer protocol of the NEO ORB. The proxy object 
then sends the translated response to the client on the 
NEO ORB. 

Fig. 88 is a high level flowchart of a process of a 
NEO client invoking a server on another ORB. At step 
552, the NEO ORB receives a request from one of its 
clients via DSI that specifies a server on another ORB. 
The bridge queries the NEO ORB's object references to 
retrieve parameter and exception definitions for the re- 
quest at step 554. At step 556, the proxy object finds the 
server object's reference from the DOMF proxy object 
reference data. 

The proxy object translates alt the DOMF specific 



data types to HOP data types at step 558, Once all the 
necessary data types are translated, the proxy object 
sends the request out via the DII HOP interface to the 
other ORB at step 560. 
5 At step 562, the proxy object receives the response/ 
exception from the DII HOP interface from the other 
ORB. In order to prepare the response for the client, the 
proxy object translates all the HOP specific data types 
to DOMF data types at step 564. Once the response is 
formatted for the client, the response/exception is sent 
back to the client via DSI at step 566. 

Fig. 9 A shows a block diagram of a client on another 
ORB invoking a sender on a NEO ORB. A NEO ORB 
602 includes a server 604 and a bridge 606. The bridge 
includes a proxy object 508 which has a storage space 
of reference data 610. Another ORB 612 includes a cli- 
ent 61 4. ORB 614 is a different implementation of NEO 
ORB 602 as it does not utilize the same transfer proto- 
col. 

If the client desires to invoke the server, the client 
sends a request to the nonlocal proxy object utilizing a 
local object reference. The proxy object translates the 
request into the transfer protocol of NEO ORB 602 (e. 
g., DOMF) and retrieves the local object reference of the 
server from reference data 610. The proxy object then 
sends the translated request to the server specified by 
the retrieved object reference. 

Proxy object 608 will receive the response (or ex- 
ception) from the server and translates the response to 
the transfer protocol of ORB 61 2. The proxy object then 
sends the translated response to the client on ORB 61 2. 

Fig. 9B is a high level flowchart of a process of a 
client on another ORB invoking a server on a NEO ORB. 
At step 652, the NEO ORB receives a request from a 
client on the other ORB via DSI HOP that specifies a 
server on the NEO ORB. The proxy object queries the 
NEO ORB'S object references to retrieve parameter and 
exception definitions for the request at step 654. At step 
656, the proxy object finds the server object's reference 
from the DOMF proxy object reference data. 

The proxy object translates all the HOP specific data 
types to DOMF data types at step 658. Once all the nec- 
essary data types are translated, the proxy object sends 
the request out via DII to the NEO server at step 660. 

At step 662, the proxy object receives the response/ 
exception from the DII interface from the server. In order 
to prepare the response for the client, the proxy object 
translates all the DOMF specific data types to HOP data 
types at step 664. Once the response is formatted for 
the client, the response/exception is sent back to the 
client on the other ORB via DSI HOP at step 666. 

While the above is a complete description of pre- 
ferred embodiments of the invention, various alterna- 
tives, modifications and equivalents may be used, it 
should be evident that the present invention is equally 
applicable by making appropriate modifications to the 
embodiments described above. For example, embodi- 
ments have been described for providing communica- 
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tion between a NEO ORB and another ORB. However, 
the invention may be utilized to provide communication 
between many different implementations of ORBs. 
Therefore, the above description should not be taken as 
limiting the scope of the invention which is defined by 
the metes and bounds of the appended claims and their 
full scope of equivalents. 



Claims 

1 . A method of providing communication in a computer 
system between a first object request broker utiliz- 
ing a first transport protocol and a second object re- 
quest broker utilizing a second transport protocol, 
comprising the steps of: 

storing within the reference data of a proxy ob- 
ject a reference to a server object; 
the proxy object receiving a request in the first 
transport protocol from a client object on the 
first object request broker; 
the proxy object translating the request to the 
second transport protocol; and 
the proxy object sending the translated request 
to the server object specified by the stored ref- 
erence. 

2. The method of claim 1 , wherein the translating step 
includes the step of translating all data types in the 
request that are specific to the first transport proto- 
col to the second transport protocol. 

3. The method of claim 1 , further comprising the step 
of the proxy object receiving a response in the sec- 
ond transport protocol from the server object on the 
second object request broker. 

4. The method of claim 3, further comprising the step 
of the proxy object translating the response to the 
first transport protocol. 

5. The method of claim 4, further comprising the step 
of the proxy object sending the translated request 
to the client object. 

6. The method of claim 3, further comprising the step 
of translating all datatypes in the response that are 
specific to the second transport protocol to the first 
transport protocol. 

7. The method of claim 1 , wherein the proxy object is 
in a bridge application. 

8. The method of claim 1 , wherein the proxy object is 
located on the first object request broker 

9. The method of claim 1 , wherein the first transport 



protocol is DOMF. 

10. The method of claim 1, wherein the second trans- 
port protocol is NOR 

5 

11. A computer program product for providing commu- 
nication between a first object request broker utiliz- 
ing a first transport protocol and a second object re- 
quest broker utilizing a second transport protocol, 

10 comprising; 

a computer readable storage medium storing a 

computer program comprising: 

code that stores within the reference data of a 

ts proxy object a reference to a server object; 

code for the proxy object that translates a re- 
quest in the first transport protocol from a client 
object on the first object request broker to the 
second transport protocol; and 

20 code for the proxy object that sends the trans- 

lated request to the server object specified by 
the stored reference. 

12. The computer program product of claim 11 , further 
25 comprising code that translates all data types in the 

request that are specific to the first transport proto- 
col to the second transport protocol. 

13. The computer program product of claim 11, further 
30 comprising code for the proxy object that translates 

a response in the second transport protocol from 
the server on the second object request broker to 
the first transport protocol. 

35 1 4. The computer program product of claim 1 3, further 
comprising code for the proxy object that sends the 
translated request to the client object. 

15. The computer program product of claim 13, further 
40 comprising code that translates all data types In the 

response that are specific to the second transport 
protocol to the first transport protocol. 

1 6. The computer program product of claim 1 1 , wherein 
45 the proxy object is declared in a bridge application. 

17. The computer program product of claim 11 , wherein 
the proxy object is on the first object request broker. 

50 1 8. The computer program product of claim 1 1 , wherein 
the first transport protocol is DOMF. 

19. The computer program product of claim 1 1 , wherein 
the second transport protocol is HOP 

55 

20. A system for providing communication between dif- 
ferent implementations of object request brokers, 
comprising; 
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a first object request broker utilizing a first 
transport protocol; 

a client object on the first object request broker; 
a second object request broker utilizing a sec- 
ond transport protocol, the first and second s 
transport protocols being different; 
a server object on the second object request 
broker; and 

a proxy object that translates a request in the 
first transport protocol fronn the client object to io 
the second transport protocol and sends the 
translated request to the server object specified 
by a reference to the server object stored in the 
reference data of the proxy object. 

IS 

21. The system of clainn 20, wherein the proxy object 
translates all data types in the request that are spe- 
cific to the first transport protocol to the second 
transport protocol. 

20 

22. The system of claim 20, wherein the proxy object 
translates a response in the second transport pro- 
tocol from the server on the second object request 
broker to the first transport protocol. 

2S 

23. The system of claim 22, wherein the proxy object 
sends the translated request to the client object. 

24. The system of claim 22, wherein the proxy object 
translates all data types in the response that are 30 
specific to the second transport protocol to the first 
transport protocol. 

25. The system of claim 20, further comprising a bridge 
application that includes the proxy object. 55 

26. The system of claim 20, wherein the proxy object is 
on the first object request broker. 

27. The system of claim 20, wherein the first transport 40 
protocol is DOMF. 

28. The system of claim 20, wherein the second trans- 
port protocol is MOP. 
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